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DETAILED ACTION 

1 . This action is responsive to the Apphcant's response filed 3/17/08. 

As indicated in Applicant's response, claims 1,3, 11, 24-26, 29, 35-36 have been 
amended; and claims 1-9, 1 1-19, 21, 24-26, 29-30, 34-36 are pending in the office action. 
Specification, Claims Objections 

2. The disclosure is objected to because of the following informalities: the sentence 'In 
other words, compliance with a dependence graph . . . from the sequential application program' 
(pg. 15,2°'* para) amounts to an improperly constructed clause - i.e. including a unfinished 
subordinate clause. 

3. Claim 1 1 is objected to because of the redundant 'are modified' (line 9) before 'to reduce 
an amount of instructions'. 

4. The language recited as 'thread program loops' (e.g. claims 21, 24-26) appears to be an 
overloaded phraseology, and based on a lack of definition thereof anjrwhere in the Specifications 
(Note: wherein the above phrase namely, thread-program-loop - is not mentioned once ), this 
language cannot not be interpreted in light of standard lexicographic connotation; hence amounts 
to a terminology rather idiomatic or far-fetched beyond undue effort using simple interpretation, 
i.e. a non-ordinary but unsupported technical jargon; and as such, this phraseology will be treated 
as mere program loops or program threads. 

Appropriate correction is required. 

Claim Rejections - 35 USC § 112 

5. The following is a quotation of the first paragraph of35U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such Ml, clear, concise, and exact terms as to enable any person skilled in the art to which it 
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pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of canying out his invention. 

6. Claim 24-25 are rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply with 
the written description requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to reasonably convey to one skilled in the relevant 
art that the inventor(s), at the time the application was filed, had possession of the claimed 
invention. The partitioning step of claim 24 as recited, includes 'generating the plurality of 
application program threads according to the thread count to synchronize access ... among the 
thread program loops' and this generating process based on thread count for synchronizing 
access among 'thread program loops' is deemed not sufficiently described in the Specifications 
for one to acknowledge that the inventor does possess this limitation. According to the claim, 
the generating of threads according to a count is done prior to processing critical sections to 
reduce code amount of these sections. The specifications regarding a partitioning process 
(emphasis added) does not have a clear step by which based on a thread count (of a multi- 
threaded architecture), a plurality of 'application program threads' are generated 'to sjmchronize 
access to' the sections identified from the 'receiving' step but prior to a 'reducing' step; nor is 
there one disclosure section about how a thread count is being obtained (from a multi-threaded 
architecture) prior to partitioning (see step 590 Fig. 16) or generating of 'application program 
threads', notwithstanding insufficient details as to how a multi-threaded sequential program is 
being partitioned. Such insufficiency can observed as an absent definition as to what this 
'partition' is all about (e.g. is this a block of code, a group of construct representing a thread or a 
critical section, or a plurality of critical sections according to some criteria?), and/or absence of a 
semantic clarification on the phrase 'the thread program loops' or 'receiving . . . the identified 
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critical sections' (Note: partitioning in claim 21 is recited prior to the synchronizing access to 
identified sections). Lacking definite language as to suggest that plurality of program threads 
are actually partitions, it is not clear whether the Disclosure supports whether partitioning 
amounts to (i) just yielding of plurality of threads based on a count, or (ii) generating of plurality 
thereof based a access synchronization, none of which being described clearly in the Disclosure; 
(iii) generating for synchronizing is done prior to code reduction within the critical sections 
being received. For example, step 590 (Disclosure, Fig. 16) mentions about "partition into" prior 
to executing of threads in parallel; but this is not same as using a count to generate plurality of 
threads prior to reducing as claimed, this reducing (' . . .processing the identified critical sections 
to reduce . . . ') apparently being done in a previous step 520 (Fig. 5; to reduce an amount of 
instructions - last para, pg. 9; code motion - 3^** para, pg. 10), not after a count-based 
partitioning. The claim is not supported by, inter alia, the sequence layout of Fig. 5 and 16. 
There is no description that would show creating of a partition in light of a thread count, nor is 
there thread count being obtained among the multi-threaded architecture as recited; nor is there 
an actual generating step according to such count in the purpose of synchronizing access, prior to 
the reducing step (emphasis added). The inventor is deemed not in possession of the partitioning 
steps as laid out fi-om claim 24, hence this sequence as claimed would be subsumed in the 
context of claim 21, prior to executing and synchronizing step, and no weight will be given to the 
'generating ... according to ... thread count ... to synchronize access to ... thread program loops'; 
e.g. the language of the claim as whole amounting to just the steps of receiving and processing. 

Claim 25 is also rejected for not remedying to the above lack of support fi-om the 
Disclosure. 
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7. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

8. Claims 1-9, 1 1-19 are rejected under 35 U.S.C. 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. Claims 1, 19 are rejected as being incomplete for omitting 
essential structural cooperative relationships of elements, such omission amounting to a gap 
between the necessary structural connections. See MPEP § 2172.01. The omitted structural 
cooperative relationships are: The step of 'concurrently executing' of thread partitions is deemed 
not reasonably founded on the forming of updated node of the CFG or 'execution of critical 
sections', and there is a gap being undefined in terms of structural relationship between 'thread 
partitions' being generated and the 'updated nodes' of the CFG loop or the 'critical sections' 
being synchronized. The 'synchronizing' step {execution of the identified critical sections) 
appears uncorrelated to the 'thread partitions' of the executing step; that is. the Disclosure does 
not supply details in regard to what generating 'thread partitions' from a CFG loop is all about; 
and based on the recited 'conciirrently executing' one cannot see how 'threads' from a CFG are 
being partitioned such that when in partitioned form these threads are executed in relation to the 
'critical sections' being synchronized, absent any clear teaching on how threads thus formed 
relate to the very bounded nodes of the updated CFG, and absent defined teaching about what 
exactly constitute a partition of threads. Lexicographically, a partition of elements cannot be 
just a assorted plurality of nodes or of threads, when there is no disclosed criteria to go about this 
partitioning process to otherwise preclude it from standard language understanding; and likewise, 
one (skill in the domain of compiler arts) cannot construe a group of runtime threads with a 
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group of nodes on a static tree, none of which concept (i.e. partitioned threads and critical node 
sections) being clearly established in the Disclosure (and claims) to sufficiently explain how 
'thread partitions' (for a runtime) are derived fi-om the static CFG nodes or sections (HOW in 
terms of a compilation step, a conversion utility, a source code?). One cannot make use of the 
invention when, as claimed, the invention of claims 1 and 19 does not interrelate 'thread 
partitions' and boundary-based modification of static nodes of the CFG, particularly when the 
entire Disclosure does not provide a single specification that would clearly describe what exactly 
a 'thread partition' is all about. Such deficiency has been raised in the USC § 1 12, first paragraph 
from above, as Figure 16 does not help put forth how 'thread partition' is actually generated on 
the basis of Figure 8 or 9, when all of which are for depicting a CFG-nodes analysis context, i.e. 
analysis far remote from a runtime thread generation —or partition thereof— for dynamic 
synchronizing. The Disclosure does not solve the lack of teaching in providing explicit utility as 
to how a partition is achieved in executable form, nor does the Specifications give a definition of 
what this term 'partition' really entails in terms of executable threads. For one of ordinary skill 
in the art interpreting a thread execution context, there appears to be a omission in teaching in 
terms of how partitioning of threads tightly correlates with the (CFG-based) code reduction of 
the critical sections, or how the sections of the CFG become implemented as threads suitable for 
runtime synchronization as claimed. In light of the lack of essential interrelationship between 
the elements being claimed, the executing of 'thread partitions that are generated from the 
modified CFG' will bear no substantial merits, and will be treaded as some execution based on 
the results of the modified CFG; and the "partitions" as claimed will be treated as mere modified 
sections of the tree being compiled. 
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Claims 2-10, and 12-19 are rejected for not remedying to the omitted teaching such as to 
link how runtime based on thread partition correlates to modified node of analysis of a CFG 
sections. 

Claim Rejections - 35 USC § 103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
maimer in which the invention was made. 

10. Claims 1-2, 1 1-12, 21, 24, 26, 29, 34-35 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Sohi et al, "Multiscalar Processors", 1995, ACM 0-89791-698; pp. 414-425 
(hereinafter Sohi) 

As per claim 1, Sohi discloses a method comprising: 

building a control flow graph (CFG) for a loop body of a sequential application program 
to form a CFG loop (e.g. CFG ... entire loop - sec 2.1, L col. pg. 415); 

updating nodes of the CFG loop to enclose identified sections of the sequential 
application program within corresponding pairs of boundary instructions (e.g. partitioned ... 
tasks - R col. pg 414; partitioned ... boundaries of a task ... instruction at ... exiting edges — R 
col. pg. 417; iteration ... sequential instruction stream ... Head and tail ... current tasks ... 
values are bound to storage ... registers and memory - pg. 415, bottom R to pg. 416, top L col.); 
and 

modifying the updated nodes of the CFG loop to reduce an amount of instructions 
between the corresponding pairs of boundary instructions to form a modified CFG loop (e.g. pg. 
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416, R col. top & middle - Note: retiring task with readjusted path based on register value at 
head and tail recordings reads on reducing code between boundaries - see sec 3, pg. 419); 

concurrently executing (sec 3.1.1 pg. 419) a plurality of thread partitions that are 
generated (e.g. search ... linked list parallel execution - bottom R col. pg. 416 to top 417 L col; 
Fig. 4 - Note: updating and resolving values via traversing a CFG for parallel re-allocating of 
correctly resolved tas]<; each in its runtime own context reads on generating of thread partitions - 
R col. pg. 417; each of which fetches and executes the instructions in its task -see sec 6, pg. 425; 
threads ... multiscalar processor - pg. 422, R col. top) from the modified CFG loop; 

execution of the identified sections of the sequential program among the plurality of 
concurrently executing application program threads to ensure that the identified sections are 
executed in a sequential thread order (e.g. sec 3.1.1 pg. 419). 

But Sohi does not explicitly disclose that the identified sections are critical sections and, 
based on which to partition and synchronizing execution of those identified critical sections. 
However, Sohi teaches synchronizing in view of memory accesses to ensure no conflicts and this 
is strongly suggestive on avoiding contention for variable access (e.g. offending accesses - top L 
col. pg. 420) among instructions being traversed during Sohi's CFG partitioning; hence discloses 
addressing memory accesses in terms that they are critical as in being potentially problematic to 
the resource dependency related to the parallel execution of tasks. To that effect it can be 
reasonable to say that Sohi addresses critical sections; hence, this 'critical section' limitation 
would have been if not disclosed, then obvious. For one skill in the art at the time the invention 
was made it would have been obvious to implement the boundary instructions by Sohi so that 
regions being identified as register-related accesses (see L col. pg. 416; sec 2.2, pg 417, L col) 
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are critical memory access regions on the CFG in light of the dependency of potential successors 
with respect to a predecessor in the CFG (e.g. sec 3.1.1, pg. 419-420) based upon which 
effectuate synchronized access execution thereof, because this would enforce a more proper 
boundary instructions to address such potential contention between successor and predecessor 
task or thread in the sections being analyzed in Sohi static setup (see Fig. 2, pg 415; task 
descriptor - pg. 417-418) 

As per claim 2, Sohi (in view of the rationale in claim 1) discloses wherein updating the 
CFG loop comprises: 

selecting an identified critical section of the sequential application program (Fig. 2, pg 
415; task descriptor - pg. 417-418); and inserting boundary instructions at a top node and a 
bottom node of the CFG (e.g. Head, Tail - Fig. 1, pg. 415); 

repeating the selecting, inserting and inserting for each identified critical section of the 
sequential application program (e.g. R col. pg. 417; pg. 415, bottom R to pg. 416, top L col. ). 

As for the inserting recited as: inserting an await instruction within a top node of the 
CFG loop; inserting an advance instruction within a bottom node of the CFG loop, this is 
deemed disclosed by Sohi, as follows. 

Sohi discloses a multiscalar model of execution uses a CFG to inspect instruction 
dependency per tasks per processor for re-ordering based on path inspection (see pg. 414, R 
column; col. 415, R col; re-ordered - sec 4.1) and one such task being inspected is coordinated 
with bit or mask implemented as an instruction at the beginning of a CFG region just so said 
instruction would indicate a wait within a subsequent forward step dependent on whether 
resoiirces are properly allocated to be released for the awaiting task to continue or advance (see 
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must wait ...to release in order to continue - pg. 417, R col; pg 418, L col). Hence, Sohi also 
discloses a wait at the top of a critical section and an advance when resources are correct for 
resuming a waiting task. 

As per claim 11, Sohi discloses an article of manufacture including a machine readable 
medium having stored thereon instructions which may be used to program a system to perform a 
method, comprising: 

building a control flow graph (CFG) for a loop body of a sequential application program 
to form a CFG loop; 

updating nodes of the CFG loop to enclose identified sections of the sequential 
application program within corresponding pairs of boundary instructions; and 

modifying the updated nodes of the CFG loop [are modified] to reduce an amount of 
instructions between corresponding pairs of bonding instructions to form a modified CFG loop; 
concurrently executing a plurality of thread partitions that are generated from the 

modified CFG loop; 

execution of the identified sections of the sequential program among the plurality of 
concurrently executing apphcation program threads to ensure that the identified critical sections 
are executed in a sequential thread order. 

All of which limitations have been addressed in claim 1 . 

But Sohi does not explicitly disclose that the identified sections are critical sections and, 
based on which to partition and synchronizing execution of those identified critical sections. This 
limitation has been addressed in claim 1. 

As per claim 12, refer to claim 2. 
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As per claim 21, Sohi discloses a method comprising: 

partitioning a sequential application program into a plurality of application program 
threads according to a thread count (e.g. search ... linked list parallel execution - bottom R col. 
pg. 416 to top 417 L col; Fig. 4 - partitioned node on CFG leading to reordering for task 
execution in parallel reads on generating of thread partitions according to thread count - see: 
threads ... multiscalar processor - pg. 422, R col. top - Note: 'thread count' not given actual 
merits - see USC 1 12, 1^* para rejection) of a multi-threaded architecture; and 

concurrently executing the plurality of application program threads (see: each of which 
fetches and executes the instructions in its task - see sec 6, pg. 425; threads ... multiscalar 
processor - pg. 422, R col. top) within a respective thread of the multi-threaded architecture; and 

access to identified sections of thread program loops of the sequential application 
program among the plurality concurrently executing application program threads to execute the 
identified critical sections of the thread program loops in sequential thread order (sec 3.1.1 pg. 
419). 

But Sohi does not explicitly disclose that the identified sections being synchronized are 

critical sections and synchronizing access of said critical sections; however, this limitation has 

been deemed an obvious limitation as set forth in claim 1 . 

As per claim 24, Sohi discloses wherein the partitioning of claim 21 comprises: 
receiving an indication of the identified critical sections within the sequential application 

program (CFG ... entire loop - sec 2.1, L col. pg. 415 ); 

processing identified critical sections to reduce an amount of code (e.g. confirm ... 

correct execution ... correct path ... CFG is resolved incorrect must be squashed ... correct data 
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recovered . . . retiring the task ... updating the head pointer- pg. 416, R col. top & middle - 
Node: eliminate task for which resources are not proper reads on reducing code between 
boundary of critical sections; sec 3.1 pg. 419 ) contained within the critical sections of the thread 
program loops. 

Sohi does not explicitly disclose generating plurality of application program threads 
according to the thread count to synchronize access to the identified critical sections among the 
thread program loops (Note: partitioning is not treated as prior to reducing sections of CFG - see 
use 1 12, 1^* para rejection); however disclose identifying of sections within boundaries and 
applying techniques to reduce code (partitioned ... boundaries of a task ... instruction at ... 
exiting edges — R col. pg. 417; iteration ... sequential instruction stream ... Head and tail ... 
current tasks ... values are bound to storage ... registers and memory - pg. 415, bottom R to pg. 
416, top L col). In light of the concurrent execution of the updated nodes based on the CFG 
analysis, the concept of reorganizing the nodes with boundaries suggest a repartitioning of 
identified sections of the program loop. It would have been obvious for one skill in the art at the 
time the invention was made to modify the loop program as approached by Sohi so that 
partitioning of code in order for enable synchronization of runtime threads to be carried out 
according to such code reduction analysis, because modifying in order to reschedule according to 
critical sections entails requirement synchronized thread behavior and data access within 
sequential loop iteration, and adjusting as by Sohi based on such repartitioning to yield 
executable and synchronized threads would support Sohi's very intention, in light of the critical 
sections as addressed above. 
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As per claim 26, Sohi discloses an article of manufacture including a machine readable 
medium having stored thereon instructions which may be used to program a system to perform a 
method, comprising: 

partitioning a sequential application program into a plurality of appUcation program 
threads according to identified sections within the sequential application program; and 

concurrently executing the plurality of application program threads within a respective 
thread of a multi-threaded architecture; and 

access to the identified sections among the plurality of concurrently executing application 
program threads to ensure that the identified sections 
are executed in a sequential thread order; 

all of which having been addressed in claim 21 . 

But Sohi does not explicitly disclose that the identified sections are critical sections and 
synchronizing access of those sections; however, this limitation has been deemed an obvious 
limitation as set forth in claim 1 . 

As per claim 29, refer to claim 26 

As per claim 34, Sohi discloses a system comprising: a processor; a memory controller 
coupled to the processor; and a DDR SRAM memory coupled to the processor, the memory 
including a compiler is operable to cause 

partitioning of a sequential application program into a plurality of application program 
threads according to identified sections within the sequential application program to enable 

concurrent execution of the plurality of application program threads within a respective 
thread of a multi-threaded architecture and 
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to access to the identified sections among the plurality of concurrently executing 
application program threads to ensure that the identified sections are executed in a sequential 
thread order; 

all of which having been addressed in claim 21 . 

But Sohi does not explicitly disclose that the identified sections are critical sections and 
synchronizing access of those sections; however, this limitation has been deemed an obvious 
limitation as set forth in claim 1 . 

As per claim 35, Sohi discloses wherein the compiler to cause building a control flow 
graph (CFG) for a loop body of a sequential application program to form a CFG loop to cause an 
update of nodes of the CFG loop to enclose identified critical sections of the sequential 
application program within pairs of boundary instructions (e.g. partitioned ... tasks - R col. pg 
414; partitioned ... boundaries of a task ... instruction at ... exiting edges — R col. pg. 417; 
iteration ... sequential instruction stream ... Head and tail ... current tasks ... values are bound 
to storage ... registers and memory - pg. 415, bottom R to pg. 416, top L col) and 

to cause modification of nodes of the CFG loop to reduce an amount of instructions (e.g. 
confirm ... correct execution ... correct path ... CFG is resolved incorrect must be squashed ... 
correct data recovered . . . retiring the task ... updating the head pointer- pg. 416, R col. top & 
middle - Node: eliminate task for which resources are not proper reads on reducing code 
between boundary of critical sections; sec 3.1 pg. 419) between corresponding pairs of bonding 
instructions to form a modified CFG loop. 

1 1 . Claims 3-9, 13-19, 25, 30, 36 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Sohi et al, "MuWscalar Processors", 1995, ACM 0-89791-698; pp. 414-425; in view of 
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Vijaykumar T.N., "Compiling for the Multiscalar Architecture", University of Wisconsin, 1998, 

pp . 1-191 (her einafter Vij ayk) . 

As per claim 3, Sohi disclose await and advance instructions as in 

reordering identified motion candidate instructions within the nodes of the CFG loop with 

fixed await instructions and fixed advance instructions (see pg. 414, R column; col. 415, R col; 
re-ordered - sec 4.1; see must wait ... to release in order to continue - pg. 417, R col; pg 418, L 
col); 

but does not disclose wherein modifying (nodes of CFG loop) comprises: hoisting 

detected hoist instructions from identified motion candidate instructions within the nodes of the 
CFG loop using code motions with fixed await boundary instructions into corresponding 
predecessor basic blocks; and sinking detected sink instructions from identified motion 
candidate instructions within the nodes of the CFG loop using code motion with fixed advance 
instructions into corresponding successor basic blocks. 

The code motion based on judicious analysis of program resources based on CFG and 
program resources information collected by a compiler for scheduling a multiscalar ILP 
execution, as by Sohi, is also disclosed in Vij ayk, and according to which, Vij ayk discloses 
successor task or predecessor task susceptible to be rescheduled or stalled based on register data 
validation or prediction implemented by wait instructions or (resources) forward annotation (Fig. 
3-6, pg. 61; Fig. 4-8, pg. 100; sec 4.4.5-4.4.6); and that code motion can applied to candidature 
blocks based on a wait so to be hoisted to a higher layer of CFG critical portion (or basic blocks) 
without disrupting the structure of the tree basic block dependency (see Fig. 4-9, 4-10, pg. 101- 
102; Fig. 4-13, pg. 109); and well as sinking of instruction to send them deeper into another 
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successor CFG sub-tree (pg. 102-103; Fig. 4-10; sec 4.5.5 ,pg. 108-110; Fig 4-15, 4-16 pg. 113) 
to reduce redundant stall cycles. It would have been obvious for one skill in the art at the time 
the invention was made to implement to wait and resources forward boundary instructions by 
Sohi to that Sohi's partitioning of the modified node information based on registers also include 
code motion as to reduce unused code cycles and improve overall code size by hoisting 
instructions to where resources can be resolved earlier in the predecessor portion or forwarded 
into a successor sub-tree as explained in the multiscalar's ILP compiler by Vijayk. One would 
be motivated to do so because this enable the amount of unused cycles (e.g. in Sohi's 
predecessor or successor subtrees) be optimized and therey reduce the code between two 
bounded critical subtree via hoisting and sinking as evidenced by Vijayk in the scheduling of 
task, resources validation and look-ahead control for loop restructuring ( see pg. 60-1 17) 

As per claim 4, Sohi discloses initializing a CFG for code restructuring based on register 
data validation and tasks reducing or squashing using await for resource resolution; that is, Sohi 
discloses queue of task order for setting boundary instructions ( see queue - R col. bottom pg. 
415) and prediction with advance knowledge to reduce stalling of cycles ( see Sohi: minimizing 
cycles lost , pg. 421; predictor ... advance knowledge - sec 4.2 pg. 422) 

but does not specifically disclose wherein hoisting detected hoist instructions with fixed 
await instructions comprises: 'identifying every instruction within a basic block the CFG loop, 
excluding await instructions, as a motion candidate instructions; building an inverse graph of the 
CFG loop; initializing a hoist queue with the basic blocks fi-om the CFG loop, the basic blocks 
ordered according to a topological order indicated by the inverse graph; hoisting motion 
candidate instructions of the basic blocks into corresponding predecessor basic blocks until hoist 
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instructions are no longer detected from the identified motion candidate instructions; and 
hoisting detected hoist instructions from motion candidate instructions within a source basic 
block of the CFG loop according to a dependence graph of the sequential application program'. 

The providing of candidate motion instructions is disclosed in Vijayk using fraversal of a 
forward tree and reverse tree (Fig. 3-13, pg. 79; upward . . . reverse topological order - pg. 102); 
and using algorithm to investigate candidate instruction (set as list of task - see Fig. 3-1 1, pg 75) 
based on the free initialization and basic block resource analysis (e.g. register stalls Fig. 4-5, 4-6, 
pg. 95-96) and dependency of predecessor and successor in order to implement hoisting and 
sinking (refer to claim 3), i.e. until hoist instructions are no longer detected from the identified 
motion candidate instructions. It would have been obvious for one skill in the art at the time the 
invention was made to implement the CFG resources dependency by Sohi so that it is initialized 
in form of basic blocks with dependency of resources as by Vijayk, as well as task allocation and 
resolution of dependency based on upward and then reverse traversal, and then predicting the 
instructions exclusively within the bomdary instructions as set forth in claim 1, to promote code 
motion as set forth in claim 3 above using the teaching by Vijayk; because this would enable 
Sohi's multiscalar ILP compiler to ftirther achieve code reduction (as set forth in claim 3) and bi- 
directional establishing of adjusted dependency while searching of candidate instructions to be 
moved (sinking or hoisting - see Vijayk: pg. 101-103) 

As per claim 5, Sohi does not disclose wherein hoisting detected hoist instructions from 
the motion candidate instructions of the basic blocks comprises: 

de-queuing a basic block from the hoist queue as a current block; 
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computing hoist instructions from the motion candidate instructions based on a 
dependence graph of the sequential application program; 

hoisting the computed hoist instructions into a corresponding basic block; and 
enqueuing the current block's predecessors from the CFG loop into the hoist queue when a 

change is detected. 

Sohi discloses queue of task order for setting boundary instructions ( see queue - R col. 
bottom pg. 415) and prediction with advance knowledge to reduce stalling ( see Sohi: minimizing 
cycles lost , pg. 421; predictor ... advance knowledge - sec 4.2 pg. 422) in order to determine 
how task being initialized in a CFG (see Fig. 2, pg. 415) can be removed to reduce cycle stalling. 
Based on the code motion technique by Vijayk (refer to claim 3) using the same resource 
dependency vaUdation and sequencer/predictor as in Sohi and also in view of the dequeuing (i.e. 
enqueueing at first prior to dequeueing) of task as by Vijayk (see Control Flow heuristics, 
dequeue - Figure 3-10, pg. 74), the de-queuing of a candidate basic block for code motion — 
identified as not disclosed in Sohi— would have been obvious in view of the rationale - using the 
teaching by Vijayk ~ to address traversal of an initialized tree of CFG until hoist instructions are 
no longer detected from the identified motion candidate instructions (i.e. heuristics for 
initializing task or candidate instruction as ordered list and dequeuing one by one), in claim 4. 

As per claim 6, Sohi does not explicitly disclose identifying motion candidate 
instructions within the basic blocks of the CFG loop through dataflow analysis with fixed 
advance instructions; initializing a sink queue with the basic blocks ordered based on a 
topological order in the CFG loop; sinking detected sink instructions among the basic blocks into 
corresponding successor basic block until sinking instructions are no longer detected from the 
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identified motion candidate instructions; and reordering detected motion candidates within basic 
blocks that contain advance instructions according to the dependence graph. 

But code motion using a initialized candidate task or basic blocks using a predictor and 
dependency of register resource allocation based on such candidate instruction or basic block for 
sinking or hoisting has been addressed in dequeueing/enqueueing limitations as set forth in claim 
5 above in light of the rationale of claim 4. 

As per claim 7, Sohi does not explicitly disclose wherein sinking detected sink 
instructions among the basis blocks comprises: de-queue a basic block from the sink queue as a 
current block; computing sink instructions from motion candidate instructions based on a 
dependence graph of the sequential application program; sinking computed sink instructions into 
a corresponding successor basic block; and en-queuing a current block's successors in the CFG 
loop into the sink queue if a change is detected. But the dequeing and enqueing limitation has 
been addressed as obvious for both hoisting and sinking as set forth in claim 5 in view of the 
hoist/sink candidate or listed instructions being hoisted or sunk (until ... instructions are no 
longer detected) of claim 4. 

As per claim 8, Sohi discloses reordering the identified motion candidates instructions 
within basic blocks (e.g. part of a basic block, a basic block - sec 2.2, top L col. pg. 415) that 
contain await instructions based on a dependence graph of the sequential application program 
(refer to claim 1); but does not disclose initializing a hoist queue with the basic blocks ordered 
based on a topological order in the CFG loop; identifying motion candidate instructions within 
the basic blocks of the CFG loop through dataflow analysis with fixed advance instructions and 
fixed await instructions; hoisting detected hoist instructions among the basic blocks into 
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corresponding predecessor basic blocks until hoist instructions are no longer detected from the 
identified motion candidate instructions. 

But the initializing of basic block being bounded by some fixed AWAIT or ADVANCE 
instructions for analysis of dataflow so to hoist or sink (until hoist candidate instructions are not 
longer detected) has been addressed in claim 4. 

As per claim 9, Sohi does not explicitly disclose wherein motion candidate instructions 
hoisted out of an outmost await instruction are no longer treated as motion candidates; and 
wherein motion candidate instructions out of an outmost advance instruction are no longer 
treated as motion candidates. But the candidate instructions being hoisted from a initialized 
candidate list as by Vijayk (until hoist candidate instructions are not longer detected) amount to 
the subject matter as set forth in claim 4; and would have been obvious using the rationale of 
claims 4 and 5. 

As per claims 13-19, refer to claims 3-9, respectively. 

As per claim 25, Sohi does not disclose wherein code motion is used to reduce the 
amount of code contained within the identified critical sections of the thread program loops. But 
the hoist and sink code motion has been addressed in claim 3 above, using Vijayk. 

As per claim 30, refer to claim 25. 

As per claim 36, refer to claim 3. 

Response to Arguments 
12. Applicant's arguments filed 3/17/08 have been fiilly considered but they are not 
persuasive. Following are the Examiner's observation in regard thereto. 

35 use § 103 Rejections: 
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(A) Applicants have submitted that for claim 1, Sohi does not disclose or suggest 'modifying 
the updated nodes of the CFG loop to reduce ... to form a modified CFG loop', much less 
'concurrently executing a plurality of ... threads that are generated ... CFG loop'; and that Sohi's 
schedule for parallel execution is not 'modifying the updated nodes ... to reduce an amount of 
instructions' as above (Appl. Rmrks, pg. 13, top). The newly added limitations have been 
addressed in light of the Disclosure, and when the argument is deemed based on the newly added 
limitation the argument is considered moot, because as necessitated by the current amendment, 
the argument is deemed not appropriate with a previously effectuated rationale of Rejection. The 
cited portions of Sohi however has proffered means by which portions of a CFG nodes are 
reorganized to reflect the resuh from analyzing sections of the tree; that is, the modifying of code 
underlying this CFG analysis is disclosed. 

(B) Applicants have submitted that as recited, 'synchronizing execution' of the critical 
sections is not disclosed (Appl. Rmrks, pg. 13, middle). The rationale of rejection is based on 
the current state of the claim as of the latest state of amendment. The Argument for bringing up 
a newly added limitation has not considered the change in scope of the claims nor taken into 
consideration the new grounds of rejection. The argument regarding this 'synchronizing 
execution' is deemed largely misplaced in view of the new grounds of rejection. 

(C ) Applicants have submitted that other independent claims include feature similar to those 
of claim 1 ; hence would be patentable as much as none of the references cited fail to disclose the 
features as argued forth above. In light of the rationale that the arguments are mostly moot in 
light of the newly added features being key elements to of Applicants' line of argumentation, the 
rejection of the claims including the USC § 1 12 Rejection have to be maintained. 
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The claims stand rejected as set forth in the Office Action. 

Conclusion 

13. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Lewis Bullock can be reached on (571)272-3759. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be 
obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Elecfronic Business Center (EBC) at 866-217-9197 (toll-free). 

/Tuan A Vu/ 

Primary Examiner, Art Unit 2193 
April 10, 2008 



